Why don't you just use https://github.com/wk8/go-ordered-map to directly replace this one? I think even without enabling TransactionDeterministicOrdering(), the serialization order should still be deterministic.

So far, I wanted to start with this initial approach for a few reasons:

1. Minimize changes to existing behavior and dependencies
   Replacing the current map with something like go-ordered-map would make deterministic ordering always-on and introduce that new dependency for all users. I wanted to preserve current behavior by default and avoid adding a dependency up front.

2. Keep the change tightly scoped
   The nondeterminism only becomes an issue at the point where address lookup tables are serialized into the transaction message. Addressing it there keeps the fix focused, rather than changing the underlying data structures used throughout transaction construction.

3. Make the performance tradeoff explicit
   Deterministic ordering has a real (though small) runtime cost due to sorting (current approach), or through sacrifice of native map (e.g. go-ordered-map approach). Making this opt-in ensures that only users who need reproducible transaction bytes (tests, caching, reproducible builds) pay that cost.

I do agree though that, in the long run, it likely makes sense for transaction serialization to be deterministic everywhere by default. This PR is intended as a first, low-friction step in that direction - addressing the immediate need without forcing a broader behavioral or dependency change. With more testing, we could easily make it the default as well.

That being said, happy to switch the PR to a more aggressive approach: including always-sorted ordering or introducing an ordered map dependency... if that’s what would help get this merged

@daog1 I made an alternate implementation in #364 if you want to take a look

Great chat! Thank you for your contribution!

I saw it covered in #365, closing not, Feel free to open new PR if issues remained.